Embodiments of the present disclosure relate in particular to the technical context of Remote SIM Provisioning technology, also known as the Embedded UICC (Universal Integrated Circuit Card).
Due to new requirements of miniaturization and robustness, the industry has developed an evolution of the traditional SIM (Subscriber Identity Module) cards called “embedded UICC” (Universal Integrated Circuit Card). This evolution envisages that the SIM card is soldered (or in any case made hardly accessible) in the hosting device that can be a mobile phone, a modem, a board inserted in a device, etc.
Soldering presents distinct advantages such as the possibility of reducing the size of the SIM device and hence of the modem, the improvement of the robustness of the contacts (soldered contacts are typically more reliable than interfaces between replaceable components), the increased antitheft protection.
On the other hand, soldering a SIM (or making it hardly accessible) introduces new requirements and issues that need to be addressed, such as, because the SIM is not replaceable, means should be available to allow the operator change. In addition, specific operations (such as device repairing), that today are typically performed after the SIM removal, require a way to disable the SIM card.
To address the above requirements, the industry has defined a new technological standard called “embedded UICC” or “Remote SIM provisioning”.
The basic concepts of the new technological standard are the following: one entity is defined to allow the download/enable/delete of profiles (for instance the Issuer Secure Domain Root ISD-R, see for instance “Remote Provisioning Architecture for Embedded UICC, Technical Specification, Version 1.0, 17 Dec. 2013”) the UICC may contain several mobile network operator subscriptions; each operator subscription is represented by a “profile”; and every profile may be seen as a container; the container is managed by a security domain (for instance the Issuer Secure Domain Profile ISD-P).
In this context, FIG. 1 shows a possible architecture of a “user equipment” 10, such as a mobile device, e.g., a smartphone or a tablet, or a mobile communication module usually to be used in embedded systems.
Generally, the device 10 comprises one or more processors 102 connected to one or more memories 104. The device 10 comprises moreover at least one mobile communication interface 106 for communication with a base station BS.
For example, the mobile communication interface 106 may comprise a GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access) transceiver, W-CDMA (Wideband Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access) and/or LTE (Long Term Evolution) transceiver.
A mobile device comprises often also a user interface 110, such as a touchscreen. Conversely, a communication module to be used, e.g., in embedded systems, such as alarm systems, gas meters or other types of remote monitoring and/or control systems, often does not comprise a user interface 110, but a communication interface 112 in order to exchange data with a further processing unit of an embedded system. For example, in this case, the interface 112 may be a digital communication interface, such as a UART (Universal Asynchronous Receiver-Transmitter), SPI (Serial Peripheral Interface) and/or USB (Universal Serial Bus) communication interface. Generally, the processing unit 102 may also be directly the main processor of an embedded system. In this case the interface 112 may be used to exchange data with one or more sensors and/or actuators. For example, in this case, the interface 112 may be implemented by means of one or more analog interfaces and/or digital input/output ports of the processing unit 102.
In the memory 104 may be stored, e.g., an operating system OS being executed by the processor 102 and which manages the general functions of the device 10, such as the management of the user interface no and/or the communication interface 112 and the establishment of a connection to the base station BS via the interface 106. The memory 104 may also contain applications being executed by the operating system OS. For example, in the case of a mobile device, the memory 104 often comprises a web browser application WB.
For establishing a connection with the base station BS, the device 10 is coupled to a processing unit 108 configured to manage the identity identification of the user. For example, usually a mobile device comprises a card holder for receiving a card comprising a Subscriber Identity Module (SIM), which is usually called SIM card. Generally a corresponding SIM module may also be installed directly within the device 10. In the example of FIG. 1 it is used a Universal Integrated Circuit Card (UICC) 108, which is a smart card often used in GSM and UMTS networks. The UICC ensures the integrity and security of all kinds of personal data and typically holds a few hundred kilobytes. Also a UICC may be integrated directly in the device 10 and is in this case often called embedded UICC (eUICC).
For example, in a GSM network, the UICC 108 contains a SIM application and in a UMTS network a USIM application. A UICC may contain several applications, making it possible for the same smart card to give access to both GSM and UMTS networks, and may also provide storage of a phone book and other applications.
Accordingly, the reference to a SIM module in the following of the present description is intended to include both 2G and/or 3G SIM modules and applies also the case in which such a SIM module is provided on a SIM card.
As shown in FIG. 2, a SIM module 108 often comprises one and more processors 1082 and one or more memories 1084 for executing applications stored in the memory 1084 of the module 108. For example, the SIM module 108 may comprise in addition to the Subscriber Identity Module application (reference sign SIM in FIG. 2) at least one further application APP. For example, this application APP may be configured to communicate (directly, or indirectly via the processor 102 and possibly the operating system OS) with the mobile communication interface 106 in order to send data to and/or receive data from a remote host 30. For this purpose, the host 30 may be connected via a network 20, such as a Local Area Network (LAN) or a Wide Area Network (WAN), such as the internet, to the base station BS. Accordingly, connection between the host 30 and the UICC 108 may be established by means of the network 20, the base station BS and the communication interface 106.
Generally, the communication may be initiated by the host 30 or the UICC 108. For example, the application APP may be a web server application, which receives requests from the web browser WB of a mobile device 10 and obtains respective content from a remote host 30, such as a web server. The application APP may also be an authentication application. In this case, the host 30 may send an authentication request to the UICC 108 and the UICC 108 may send an authentication response to the host 30.
FIG. 3 shows in this respect a typical architecture of the software layers of a UICC card. Substantially, a UICC 108 comprises a hardware layer UICC_HW being represented (at least) by the processor 1082 and the memory 1084. On top of the hardware layer UICC_HW runs an operating system UICC_OS of the UICC card. Generally, the operating system UICC_OS may manage a plurality of applications. For example, in the example considered, a Java Card System JCS is executed by the operating system UICC_OS, which manages and runs applets, i.e., applications using the APIs (Application Programming Interface) provided by the Java Card System JCS.
For example, the Java Card System JCS comprises usually a SIM and/or USIM API (identified with the reference sign (U)SIM API) which manages the basic Subscriber Identity Module commands and provides functions to higher level SIM or USIM applets (identified with the reference sign (U)SIM_APP).
Generally, the communication with the remote host 30 may be performed via short messages of the Short Message Service (SMS) and/or by means of a Bearer Independent Protocol (BIP), such as GPRS, EDGE, or UMTS. The Java Card™ Platform provides a JAVA™ runtime environment, which is particularly optimized for smart cards. This technology is well known to those skilled in the art, rendering a more detailed description herein superfluous.
Often the Java Card System JCS comprises a GlobalPlatform module GP according to the “GlobalPlatform Card specification,” e.g., version 2.2.1. Also this standard is well known to those skilled in the art, rendering a more detailed description herein superfluous. Basically, the GP module provides features such as user authentication through secure channels, or the installation and remote management of the applets. For example, one of the possible encryption mechanisms managed by the GP module may be the SCP (Secure Channel Protocol) 80 specified in the technical specification ETSI TS 102 225 “Smart Cards; Secured packet structure for UICC based applications,” e.g., version 9.0.0.
The above mentioned API functions may then be used by applets, such as the SIM or USIM applet (U)SIM_APP, a basic applet B_APP and/or a secure applet S_APP.
The UICC 108 may comprise also further applications, such as a Smart Card Web Server SCWS and possible Web server applets SCWS_APP, which e.g., perform the above-mentioned web server function.
Generally, the UICC 108 may comprise not only custom applets but also native low level applications N_APP being executed directly by the operating system UICC_OS.
For example, FIG. 4 shows a typical communication by using the remote management protocol, such as the SCP 80 protocol as specified in the technical specifications ETSI TS 102 225 “Smart Cards; Secured packet structure for UICC based applications”, e.g., version 9.0.0, and in particular in ETSI TS 102 226 “Smart Cards; Remote APDU structure for UICC based applications”, e.g., version 9.2.0.
In the example considered, the remote host 30 may send a command, i.e., a Command Application Protocol Data Unit C-APDU, to an application installed on the UICC 108 and receive from the application a respective response, i.e., a Response Application Protocol Data Unit R-APDU.
For example, the host 30 may send the command C-APDU to a Short Message Service-Service Centre SMSC, which sends a short message to the device 10. The Short Message Service-Service Centre SMS-SC, may also encrypt the command C-APDU, e.g., by using the SCP80 protocol, and encapsulates the encrypted content in a SMS message, which is then transmitted by means of the base station BS to the device 10. The device 10 may recognize that the short message contains a remote management message, e.g., a SCP80 packet, and send the latter to the UICC 108 by means of a so called ENVELOPE. The UICC 108, possibly by using the functions provided by the operating system UICC_OS and the Java Card System JCS, determines the content of the SMS message, e.g., if required the UICC may decrypt the message, and forwards the content C-APDU to the target application.
In order to forward the C-APDU, the UICC 108 should be able to identify the corresponding target application. For this purpose, usually a TAR (Toolkit Application Reference) code, consisting, e.g., of 3 bytes, is associated with each applications installed in the UICC. For example, in FIG. 4 a code TAR1 is associated with the SIM application SIM_APP, a code TAR2 is associated with the application B_APP and a code TAR3 is associated with the secure application S_APP.
Accordingly, it is sufficient to include the TAR code of the target application in the short message sent to the UICC 108, e.g., in the short message header or the SCP80 packet, and the UICC has only to compare the TAR code received with the various TAR codes of the applications installed in the UICC.
Generally, instead of using short messages, any other communication could be used for exchanging remote management messages with a SIM module 108, such as a communication based on the IP protocol, e.g., the TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) protocol.
For example, the above remote management communications may be used in order to update the Preferred Roaming List (PRL), i.e., the list and priority of roaming partners, which may be stored directly within the memory of the UICC 108.
In this case, the UICC may comprise an application which manages the Preferred Roaming List and the remote host may send one or more C-APDU with the updated roaming information and the TAR code of the application to the UICC 108.
The present disclosure deals in particular with solutions for performing a management of a SIM module having installed applications provided by different mobile phone operators, i.e., a so called multi-subscription SIM, which is preferably an embedded multi-subscription SIM module, preferably a multi-subscription eUICC. For example, such multi-subscription SIM modules may be used as embedded SIM modules, e.g., eUICC, or as SIM cards to be installed in automated machines, which often are not easily reachable, such as remote monitoring and/or control systems, such as a gas meters.
FIG. 5 shows an embodiment of a multi-subscription SIM module 108a. 
In the embodiment considered, the SIM module 108a supports at least two profiles P1 and P2 of two mobile network operators. In general the SIM module 108a can support also more than two profiles, i.e., a plurality of profiles.
For example, in the embodiments considered, the software architecture is based on the Java Card System described with respect to FIG. 3. For example, also in this case, a Java Card System JCSa is executed by an operating system UICC_OS, which manages and runs applets, i.e., applications using the APIs (Application Programming Interface) provided by the Java Card System JCSa. For example, the Java Card System JCS may comprise a SIM and/or USIM API (identified with the reference sign (U)SIM API) which manages the basic Subscriber Identity Module commands and provides functions to higher level SIM and/or USIM applets. Moreover, the Java Card™ Platform may provide a JAVA™ runtime environment. In an embodiment, the Java Card System JCSa may also comprise a GlobalPlatform module GP according to the “GlobalPlatform Card specification”, e.g., version 2.2.1. The above mentioned API functions may then be used by the applets, such as the SIM and/or USIM applet (U)SIM_APP, a basic applet B_APP and/or a secure applet S_APP.
Each profile P1/P2 is represented by a memory area in the memory 1084 of the SIM card for storing applets APP, such as a respective (U)SIM_APP applet for each profile P1/P2. In the memory area may also be stored the respective authentication data AUTH of the SIM card used to access the mobile network of the mobile network operator. In various embodiments, each profile P1/P2 may also have associated a respective Over The Air (OTA) Key, which are usually used to encrypt (e.g., according to the SCP80 protocol) the remote management commands sent by a mobile network operator to a given SIM card. Usually, while the authentication data AUTH are SIM specific, often a single OTA key is used by a given mobile network operator.
In various embodiments, each profile P1/P2 may have associated a respective file system area FS, e.g., in order to store new applets APP and/or for storing user data, such as the user's contact list, or the above mentioned preferred roaming partner list.
Generally, while the profile data have been shown in the applet/application layer, each profile may also comprise applications and/or API in the Java Card System JCSa. Moreover, the profile data may also include configuration data which influence directly the API layer.
In the embodiment considered, the UICC 108a comprises moreover a profile manager application PM. For example, in the embodiments considered, this profile manager PM is provided in the API layer. However, the profile manager PM may also be at the applet layer, or be distributed between the API and the applet layers.
FIG. 6 shows in this respect a possible embodiment of a device boa, such as a mobile device or a mobile communication module, having (pre)installed the above described multi-subscription SIM module 108a, e.g., in the form of an embedded SIM module, e.g., a eUICC.
In the embodiment considered, similar to what has already been described with respect to FIG. 1, the device boa may comprise one or more processors 102a connected to one or more memories 104a. The device boa comprises moreover at least one mobile communication interface 106a for communication with a base station BS. For example, the mobile communication interface 106a may comprise a GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access) transceiver, W-CDMA (Wideband Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access) and/or LTE (Long Term Evolution) transceiver. The device boa may comprise also a user interface 110a, such as a touchscreen.
In the embodiment considered, in the memory 104a is stored an operating system OSa being executed by the processor bola and which manages the general functions of the device boa, such as the management of the user interface 110a the establishment of a connection to a base station BS via the interface 106a. 
In the embodiment considered, the memory 104a contains also an application CFG configured for communicating with the profile manager PM of the SIM module 108a in order to manage the profiles installed in the SIM module 108a. For example, in some embodiments, the application CFG is configured for communicating with the profile manager PM in order to select or enable one of the profiles P1/P2 installed in the SIM card 108a. 
For example, in an embodiment, the SIM module 108a may have preinstalled the profiles of a plurality of mobile network operators and when the device boa is started for the first time (or generally during a configuration phase), the user may activate by means of the application CFG one of the profiles P1/P2.
In some embodiments, the application CFG may be configured to install and/or update a profile in the SIM module 108a. For example, the application CFG may access a remote host in order to download a list of mobile network operators. Next the application CFG may be used to subscribe to one of the mobile network operators and obtain the respective profile data, which may then be loaded on the SIM module 108 by means of the application CFG and the profile manager PM.
Thus, several profiles can be present concurrently on the same card representing several operators. Only one profile can be enabled at any given time, all the others being disabled.
The profiles may be downloaded through remote protocol (OTA) after card issuance; profiles may also be deleted.
In the above scenario, it is apparent that each profile to be stored demands memory resources to arrange the data and applications.
The memory 1084 or 1084a includes two kinds of memory resources on smartcards. One kind is non-volatile memory (NVM), representing memory that is not reset upon card cycle (power off/power on). This memory is typically realized by using Flash memory or EEPROM memory. The second kind is volatile memory, representing memory whose value is reset at card cycle. The memory is typically realized by using RAM memory.
On current smart card products the NVM amount is by far higher than the RAM amount: as an example, a high end smart card product supports for instance 1.2 MB of Flash memory and 30 kb of RAM.
Data structures (such as files) are stored in NVM; application code and persistent data are stored in NVM as well, but application volatile variables are typically stored in RAM memory, because the memory access is much faster.
This results in the fact that the RAM memory is typically the bottleneck of the memory for downloading applications. In case of Embedded UICC, as there are several profiles each of that containing several applications, the problem is amplified: every profile has its need of volatile memory that needs to be arranged.
The problem may be addressed in many ways. A solution is to perform reservation at profile loading time. In this solution, the RAM memory is fully allocated to each and every profile at profile loading time, in particular when the profile is downloaded from remote. The total RAM memory required is the sum of all the RAM memory allocated to every profile.
By way of example, if profile P1 contains 3 applications, consuming a total of 10 kb, profile P2 contains 2 applications, consuming a total of 7 kb, profile P3 contains 2 applications, consuming a total of 9 kb, the memory is allocated to each profile P1, P2, P3 when downloaded, for a total of 26 kb required.
Such solution is very reliable (all the profile resources are guaranteed), but it is also very inefficient from the point of view of the memory usage: the memory required to arrange all the profiles is the sum of all the memory of the profiles, but such an amount of memory is not always required; in fact, only one profile is active at a time, therefore the memory allocated to the other profiles is not used. If the active profile is changed, then it is operated a power cycle reset to change the profile and this resets all the data, so the former profile memory can be deallocated.
Another solution provides reservation at memory request. In this solution, the RAM memory is allocated to every entity each time the entity requires the memory usage (dynamic approach).
By way of example, if profile P1 contains 3 applications, profile P2 contains 2 applications, profile P3 contains 2 applications, and no memory is allocated at profile download, the RAM is allocated only for the applications running.
The above solution implies that the profile RAM resources grow over time and at any time they can overflow the available memory resources.
This is dangerous on smartcards, as an application requesting memory for performing an operation and not obtaining it is subject to a fault. Faults are often used by hackers to identify security weaknesses.